chore: group dependabot into production vs non-production PRs - #411
Conversation
Split the npm ecosystem into two grouped PRs: one for the published packages' runtime + peer dependencies (production), one catch-all for everything else (development). GitHub Actions stays its own grouped PR (separate ecosystem). Uses pattern-based routing rather than dependency-type, because Dependabot misclassifies pnpm catalog dev-deps as production (dependabot-core#14824).
📝 WalkthroughWalkthroughUpdates .github/dependabot.yml to replace npm's minor/patch update-type grouping with two pattern-based groups (production-dependencies and development-dependencies), expands top-level documentation comments, and adjusts formatting in the github-actions block while preserving its existing schedule and behavior. ChangesDependabot Configuration Update
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Fallow audit reportFound 3 findings. Details
Generated by fallow. |
Fallow audit report0 inline findings selected for GitHub review. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/dependabot.yml (1)
55-73: 🧹 Nitpick | 🔵 TrivialGrouping all update types (incl. major) into one production PR is intentional, but note the CI-attribution tradeoff.
With majors and patches bundled together, a single failing major bump can block the whole PR — and grouped PRs don't indicate which dependency caused the failure, making triage slower than with the previous minor/patch-only grouping. This is explicitly a deliberate tradeoff per the doc comment, so just flagging as an operational consideration if production PRs start stalling frequently.
[reliability_and_resilience]
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/dependabot.yml around lines 55 - 73, This Dependabot grouping intentionally bundles major and non-major production updates into one PR, but the current config should clearly reflect the CI-attribution tradeoff so triage expectations are set. Update the existing grouping comments near production-dependencies in the dependabot config to explicitly note that a failing major can block the whole grouped PR and make it harder to identify the culprit dependency, while leaving the grouping behavior itself unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/dependabot.yml:
- Around line 55-73: This Dependabot grouping intentionally bundles major and
non-major production updates into one PR, but the current config should clearly
reflect the CI-attribution tradeoff so triage expectations are set. Update the
existing grouping comments near production-dependencies in the dependabot config
to explicitly note that a failing major can block the whole grouped PR and make
it harder to identify the culprit dependency, while leaving the grouping
behavior itself unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 11628e1d-a2b0-47d7-bab7-b362bbb93aff
📒 Files selected for processing (1)
.github/dependabot.yml
Summary
Reconfigure Dependabot so weekly updates arrive as one PR per bucket instead of many:
dependencies+peerDependenciesof the five published packages (the consumer-facing surface). Isolated for closer review; all update types (incl. major) grouped here.Net effect: ~1 prod PR + 1 non-prod PR + 1 actions PR per week, down from one-per-major + a grouped minor/patch.
Why pattern-based, not
dependency-typeThe obvious config (
dependency-type: production/development) is unreliable here: this repo centralizes versions in the pnpm catalog, and Dependabot currently misclassifies catalog dev-deps asproduction(dependabot-core#14824) — that would dump most dev tooling into the production group. Routing by package name (production group listed first, development"*"catch-all second, first-match wins) sidesteps the bug.Notes
zod/hono/expressintentionally land in development: they are devDependencies of the published packages (only the private example apps list them underdependencies), so their bumps don't change what consumers install. Easy to promote to production later if you'd prefer prod-level review.production-dependencies(documented inline).Config-only change; no runtime or generated-output impact.
Summary by CodeRabbit